Previous to this PR, the relationship between Log and Warning is that a Warning is contained in a Log. Because the log channel had limited capacity, a Warning event can technically be missed if the receiver is lagging behind. To compensate for this, transaction rejections at the network level were put into the Event enum, which have an unbounded channel to miss any Event. In reality though, a user would probably not want to miss any Warning at all, including transaction rejections.

As an aside, the term "failure" in FailurePayload is not correct, as a single node may reject a transaction while others accept it. Instead, the FailurePayload is renamed to RejectPayload to more accurately reflect the situation.

This PR introduces the RejectPayload into the transaction rejection variant on Warning. In addition, the Warning variant is removed from Log, and Warning events are given their own channel. Now there is a clear separation of concerns between a Log, Warning, and Event without ambiguity of what data should be in each type.

@nyonson the bulk of the refactor are one line changes to account for this new warning channel sender/receiver. I tried to break the commits into easily reviewable parts, minus the head commit that has to do some heavy lifting. Of note in that one, any time the node needs to talk to the client, it must do so through the Dialog struct. To redirect the Warning messages to the new channel instead of with Log, all that changes is the implementation of Dialog::send_warning.